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ABSTRACT 

This  paper  describes  ICL,  Illiac  Control  Language  and  the  job  parser 
which  interprets  the  ICL.   ICL  is  a  free  format,  ALGOL-like  language  which 
allows  the  user  to  specify  tasks  to  be  processed  in  serial  or  parallel  and 
provides  for  the  conditional  execution  of  tasks  dependent  upon  the  results  of 
previously  processed  tasks.   The  job  parser  builds  a  tree  which  represents  the 
ordering  of  tasks  and  dossiers,  which  contains  in  tabular  form  all  information 
about  a  task  and  its  associated  files  necessary  to  process  the  task. 
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1.   INTRODUCTION 

The  Illiac  Control  Language,  ICL,  is  the  user's  interface  to  ILLIAC  IV. 
The  job  parser  interprets  the  ICL  and  builds  a  tree  which  represents  the  entire 
job.   Each  node  represents  a  task  to  be  performed  on  the  ILLIAC  IV  or  the  B6500 
and  points  to  a  dossier  which  describes  the  task  and  the  data  files  required  by 
the  task.   Several  tasks  may  be  specified  to  be  executed  in  parallel,  since  each 
node  has  a  pointer  to  the  next  parallel  task  and  a  pointer  to  the  next  sequen- 
tial task  associated  with  it. 

Several  design  criteria  strongly  influenced  ICL.   First,  a  user  famil- 
iar with  B5500  -  B6500  control  language  should  not  have  to  learn  an  entirely  new 
language.   Second,  the  language  should  be  free  format.   Third,  the  language 
should  reflect  the  parallel  capabilities  of  ILLIAC  IV  by  allowing  the  user  to 
specify  tasks  to  be  done  in  parallel.   Fourth,  the  language  should  allow  for 
conditional  execution  of  tasks  depending  upon  the  results  of  completed  tasks. 
Fifth,  the  job  parser,  the  ICL  interpreter,  should  be  capable  of  interacting 
with  the  on-line  user,  reporting  to  him  the  status  of  his  job  and  any  errors  in 
his  ICL  code.   Sixth,  as  much  advantage  as  possible  should  be  taken  of  the  B65OO 
MCP. 

Chapter  2  describes  the  syntax  of  ICL.   Chapter  3  describes  the  job 
parser  and  gives  the  format  of  the  tables  and  dossiers  built  by  the  job  parser. 


of  a  four-quadrant  configuration. 


SYNTAX 


The  syntax  of  ICL  is  specified  in  TBNF  [1].   All  identifiers  in  ICL 
have  a  maximum  length  of  17  characters  and  are  represented  by  the  symbol  <*I> 
in  the  TBNF  productions.   The  symbol  <*N>  represents  an  integer.   The  complete 
syntax  is  given  in  the  Appendix;  the  following  description  is  intended  as  an  in- 
troduction to  ICL  and  as  a  user's  manual  for  the  first  edition. 

2.1  Task 

2.1.1  Introduction 

An  ICL  task  is  defined  to  be  a  single  program  to  be  executed  on  the 
B65OO  or  the  ILLIAC  IV  or  any  series  of  operations  which  can  be  specified  by 

a  legal  sequence  of  E-6500  control  cards.   Syntactically ,   a  task  or  tasks  may  be 

*  ** 

declared  as  a  procedure  to  be  invoked  by  the  appearance  of  a  procedure  call. 

2.1.2  Procedure  Declaration 

<procedure  declaration>  ::=  PROCEDURE  <*I>  <parameter  list>?  <insert>?  ; 

<procedure  body> 
<parameter  list>  ::=  (LIST  [<*I>  <default>?]  SEPARATOR,) 
<default>  ::=  "="  <file  identified  [2] 

The  parameter  list  allows  the  same  procedure  to  be  used  for  many  dif- 
ferent purposes  by  changing  the  calling  parameters.  The  default  option  specifies 


Procedure  declarations  will  not  be  permitted  in  the  first  edition, 
but  keep  reading  as  one  will  have  to  know  what  a  procedure  body  is. 

See  2.1.6. 


that  if  the  matching  calling  parameter  does  not  occur  then  the  parameter  will 
be  set  to  the  default. 

<insert>  ::=  IN  <B6500  disk  file  name> 

The  insert  option  allows  the  user  to  automatically  place  the  proce- 
dure into  the  library  file  given  by  the  B6500  disk  file  name. 

2.1.3  Procedure  Body 

<procedure  body>  ::=  <execute  card>  |  BEGIN  <step  block>  END 

<step  block>  ::=  [<execute  card>  [<lk   file  card>  *  |  <B6500  file  card>  *  ]*]*  | 

<  any  legal  B6500  control  card  sequence  with  the  "?" replaced  by 

"#"  > 

If  more  than  one  execution  is  specified  by  a  procedure,  the  tasks 
represented  are  processed  sequentially.   A  B65OO  control  card  sequence  is  trans- 
ferred to  a  zip  file  after  replacing  the  "##"  by  "?"  and  is  handed  to  the  B65OO 
MCP  [2]  by  the  B6500  scheduler  [3]. 

2.1. k     Execute  Card 

<execute  card>  ::=  EXECUTE  <switchset>?  <program  name>  ON  <machine  name> 

<time  limit>?  ; 
<switchset>  ::=  <switch>  := 
<switch>  : :=  SW<*N> 

Switches  SW1  through  SW255  are  global  variables  (type  integer)  avail- 
able to  the  user  to  store  the  results  of  programs.   If  the  program  is  a  system 


Library  files  are  disk  files  containing  ICL  procedures.   See  2.3.2. 


program  (e.g.  the  TRANQUIL  compiler),  the  switch  will  be  set  by  the  system  pro- 
gram to  represent  the  relative  success  or  failure  of  the  program.   If  the  pro- 
gram is  a  user  program  there  will  be  a  facility  for  passing  an  integer  between 

2k 
1  and  2  -1  to  the  operating  system  which  will  then  set  the  switch  to  this 

* 
value.   Switches  may  be  used  in  if  statements  to  specify  conditional  execution 

of  tasks. 

<program  name>  ::=  <B6500  disk  file  name> 

<machine  name>  ::=  [lU|lLLIAC  IV]  <number  of  quadrant s>? |b6500 

<number  of  quadrant s>  ::=  ([l|2|3|*+]) 

<time  limit>  : :  =  FOR  <*N> 

The  time  limit  is  given  in  terms  of  an  integral  number  of  seconds. 
EXAMPLES:   EXECUTE  SW2  :=  A/B  ON  ik   ; 

EXECUTE  C/D  ON  B6500  FOR  5  \ 

2.1.5  Ik   File  Card 

<lk   file  card>  ::=  FILE  <*I>  =  ^initialization  part>  (<disk  map  part>) ; 

IMMEDIATE  <  data  >  ##  ENDDATA  ;  ] 

The  immediate  form  of  the  ILLIAC  file  card  specifies  that  the  file 
follows  in  line  and  is  terminated  by  ##  ENDDATA  where  "##"  appears  in  columns 
one  and  two. 

<initialization  part>  ::-   [(<segments  per  record>?  <motion  part>)]? 
<segments  per  record>  ::=  <*N> 


*See  2.2.2. 

** 

for  four-quadrant  configuration. 


Motion  part>  ::  =  [MOVE  ON  LIST  [<B6500  disk  file  name>  |  §   <*I>] 
SEPARATOR  &]?  [MOVE  OFF  [<B6500  disk  file  name>  | 

The  initialization  part  specifies  the  number  of  ILLIAC  IV  disk  seg- 
ments per  record  (default  of  one),  where  the  file  comes  from  and  where  it  is  to 
be  placed  when  the  task  is  completed.   Several  B6500  disk  files  may  be  concaten- 
ated  to  make  one  ILLIAC  file  at  initialization  time.   In  order  to  be  saved  a 
file  must  be  moved  off  the  ILLIAC  disk. 

<disk  map  part>  ::  =  <prefix>  «map  element  list>)  |  <map  element  list>  | 

SIZE  OF  [<B6500  disk  file  name>  |  #  <*I>] 

The  SIZE  OF  form  of  the  disk  map  part  implies  that  the  user  does  not 
want  to  map  his  data  onto  the  disk  in  any  special  manner  and  knows  only  that 
his  file  is  the  same  size  as  some  file  on  the  B6500  disk. 

<prefix>  ::=  <*K>  |  [@]?  <iocation>  |  location  list> 

<location>  ::=  EU  <euno>  |  SU  <suno>  |  TRK  <trkno>  |  SEG  <phase> 

<location  list>  ::=  (LIST  <location>  SEPARATOR  ,) 

<euno>  : : =  0  '  1 

<suno>*::=0  |  1  |  2  |  3  |  k\ 5  |  &   |  7  I  8  |  9  |  10  |  11 

<trkno>  : :  =  <  integer  between  0  and  hrj   inclusive  > 

<phase>  : : =  <  integer  between  0  and  II99  inclusive  > 

The  disk  map  part  of  the  ILLIAC  file  card  allows  the  user  to  map  his 
data  onto  the  disk  in  the' manner  which  affords  him  the  most  efficiency.   A  pre- 
fi^may  indicate  that  the  specification  which  follows  is  to  be  repeated  one  or 

later.    ^6Se  ^^  ^  ValM  f°r  the  first  system'   ^y  will  be  changed 


more  times;  is  to  be  placed  on  a  particular  electronics  unit,  storage  unit,  or 
track;  or  is  to  "be  phased  relative  to  a  particular  segment  number.   Electronics 
units,  storage  units,  tracks,  and  segments  can  be  expressed  in  absolute  or  rela- 
tive terms.   The  presence  of  "@"  before  a  prefix  indicates  that  the  prefix  is 
absolute,  e.g.  @EU1,  @SU5  implies  that  space  for  the  specification  following 
is  to  be  reserved  on  the  EU  and  SU  which  are  respectively  numbered  1  and  5  by 
the  hardware.   Otherwise  a  prefix  is  relative,  e.g.  SU5  implies  that  the  follow- 
ing specification  is  to  be  placed  on  any  SU  and,  once  chosen,  that  SU  will  be 
known  as  SU5  in  case  any  later  specifications  require  placement  on  the  same  SU. 

EXAMPLES  OF  PREFIXES: 

Make  2  copies  of  the  following  specification. 
(@SUO,  EUl)         Space  for  the  following  specification  is  to  be  reserved 

on  absolute  storage  unit  0  and  relative  electronic  unit 
1. 
@SEG15  For  the  following  specification  relative  segment  0  is 

to  be  set  to  absolute  segment  15- 

<map  element  list>  : :=  LIST  <map  element>  SEPARATOR  , 

<map  element>  ::=  <*N>  <qualifier>  :  <*N>  <size  qualifier>  | 

<*N>  <size  qualifier>  -  <*N>  <size  qualifier>  | 

<*N>  <qualifier>  :  <repetitive  element>  | 

<*N>  C  <size  qualifier>  |  <*N>  <T  qual>  | 

<prefix>  (<iiiap  element  list>) 
<Tqual>  ::=  [T  |  R  |  S]  <  any  alphameric  string  >  |  <  > 
<size  qualifier>  ::=  [R   S]  <  any  alphameric  string  >  |  <  > 
<qualifier>  ::=  [D  |  M  |  R  \    S]  <  any  alphameric  string  >  |  <  > 
Repetitive  element>  ::=  (<*N>  @  <*N>  <qualifier>  :  <*N>  <size  qualifier>) 


There  are  several  forms  of  the  map  element;  this  variety  allows  the 
user  to  think  of  the  disk  in  terms  of  degrees,  milliseconds,  segments  or  re- 
cords.  The  user  requests  disk  space  in  units  of  segments,  records  or  tracks. 
(E.g.  200,  1+00S,  2TRK. )   If  there  is  no  qualifier  the  request  is  assumed  to  be 
a  request  for  records.   He  may  ask  for  a  contiguous  portion  of  the  disk  by 
appending  a  "C  to  his  request  (e.g.  200C,  J+OOC  SEG).   He  may  ask  that  a  re- 
quest be  phased  with  respect  to  a  relative  or  absolute  zero  by  preceding  his 
request  with  a  phase  specification  in  terms  of  degrees,  milliseconds,  segments, 
or  records.   A  phased  request  is  by  implication  a  contiguous  request.   (E.g. 
10D:  100,  5MILLISEC:   100SEGMENTS. )   Checking  is  done  on  the  first  letter  of 
the  qualifier;  any  blank  free  alphameric  sequence  is  allowed  to  follow;  hence 
D  is  equivalent  to  DEGREES  is  equivalent  to  DEG,  etc. 

The  conversion  between  degrees  and  segments  is  360°  per  1200  segments. 
Hence  3°  corresponds  to  10  segments.   Any  phase  request  in  terms  of  degrees 
which  is  not  a  multiple  of  three  will  be  handled  as  if  it  were  the  next  higher 
multiple  of  three  (e.g.  a  request  for  10DEG  is  equivalent  to  a  request  for 
12DEG) .   The  disk  has  a  kO   millisecond  rotational  latency  and  hence  one  milli- 
second corresponds  to  30  segments. 

The  repetitive  element  requests  a  given  block  of  disk  space  to  be  re- 
peated at  a  given  interval  for  a  specified  number  of  times.   For  example, 
5  @  10MS:   7S  reserves  five  blocks  of  seven  segments  where  the  first  segments 
of  any  two  consecutive  blocks  are  separated  by  10  milliseconds. 

EXAMPLES : 

10  DEG:   10  Starting  at  degree  10  (converted  to  segment 

ho)    space  for  10  records  is  reserved. 
500C  Space  for  500  contiguous  records  is  reserved. 

100S  -  500 S  Starting  at  segment  100,  500  segments  are 

reserved. 
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2(@EU0(10D:  10,  100C),  50CS)      On  absolute  electronic  unit  0,  starting  at 

degree  10,  space  for  10  records  is  reserved, 
space  for  an  additional  100  contiguous  re- 
cords is  reserved  on  absolute  electronic 
unit  0.   50  contiguous  segments  are  reserved 
anywhere  on  the  disk.   Two  copies  of  the  en- 
tire specification  are  made. 

An  entire  Ik   file  card  looks  like: 

FILE  C  =  (2  MOVE  ON  A/B  &  Al/Bl)(  @  SEG5  (@EU0  (100:   500,  200:   500 ),  @  EU1 
(100:   500,  200:   500)),  1000C) 

and  conveys  the  following  information: 

1)  The  file  is  blocked  two  segments  per  record. 

2)  The  file  is  to  be  initialized  from  B6500  disk  file  A/B  concatenated  with 
B6500  disk  file  Al/Bl. 

3)  The  file  is  not  to  be  saved. 

k)     On  absolute  electronic  unit  0,  relative  segment  0  is  to  be  set  to  absolute 
segment  5-   Space  for  500  records  (1000  segments)  starting  at  relative 
segment  200  (absolute  segment  205,  relative  record  100 )  and  for  500  more 
records  starting  at  relative  segment  ^00  (absolute  segment  *+05,  relative 
record  200)  is  to  be  reserved  on  electronic  unit  0. 

5)  The  same  request  as  k   is  to  be  repeated  on  absolute  electronic  unit  1. 

6)  1000  additional  contiguous  records  (2000  segments)  are  reserved;  they  may 
be  anywhere  on  the  disk. 


2.1.6  B6500  File  Card 

<B6500  file  card>  ::=  FILE  <*I>  =  <file  identified 

<file  identifier>  ::=  <B6500  disk  file  name>  <options>  |  <immediate  file>  | 

<unit  file> 

<options>  : :=  <  to  be  specified  > 

<Bb500  disk  file  name>  ::=  LIST  <*I>  SEFAKATOR/ 

<unit  file>  ::=  <  to  be  specified  > 

<immediate  file>  : :  =  FILE  <*L>  =  IMMEDIATE  <data>  ##   ENDDATA 

Unit  files  are  not  implemented  in  the  first  version.   Immediate  files 
have  the  same  format  and  meaning  as  in  lh   file  card.   Options  will  be  identical 
to  the  options  allowed  by  Burroughs  6500  MCP  for  their  file  cards  (not  as  yet 
released)  [2]. 

A  B65OO  file  card  which  follows  a  B6500  execution  request  has  the 
obvious  meaning.   However,  a  B65OO  file  card  may  appear  after  an  ILLIAC  IV  exe- 
cution request.   In  this  case,  the  file  referred  to  is  assumed  to  be  a  data 
file  for  use  by  the  job  partner. 

2.1.7  Examples  of  Procedures 

PROCEDURE  STEP1  (X  =  Xl/Yl); 
BEGIN 

EXECUTE  A/B  ON  ILLIAC  IV  FOR  5; 

FILE  C  =  (MOVE  ON  #X)((@SEGO,  EU1,  SUO)(0:   500,  1000:   100), 
10M:   50,  100) 

FILE  D  =  (SIZE  OF  M/N/Q) ; 
END; 

The  #<*!>   construct  permits  quick  recognition  of  the  parameter  as  it 
appears  in  the  text.   If  in  the  procedure  call  the  parameter  X  is  not  specified, 


10 

then  file  C  will  be  initialized  from  file  Xl/Yl.   Note  that  the  parameters  are 
not  positional  and  may  therefore  occur  in  any  order.   Procedure  STEP1  may  be 
invoked  by  the  following  calls: 

STEP1  (X  -  Q/R) 
STEP1 

PROCEDURE  STEP2 
BEGIN 

EXECUTE  SW5  :=  A/B  ON  B65OO; 

FILE  M  =  IMMEDIATE; 
{ data} 

#  ENDDATA; 
END; 

PROCEDURE  STEP3 
BEGIN 

##  COMPILE  MY/PROG  XALGOL  SYNTAX; 

#  XALGOL  FILE  CARD  =  S0URCE/J0B1  SERIAL; 
END; 

2.2  Logic 

2.2.1  Logic  Card 


* 


<logic  card>  ::=  BEGIN  <logic  body>  END  |  <procedure  call> 

<logic  body>  ::=  LIST  <parallel  statement>  SEPARATOR  [NEXT  |  ;] 

<parallel  statement>  :  ;=  LIST  <step>  SEPARATOR  [&  |  ALSO]  |  <set  switch  statement > 


A  special  terminal  symbol  following  the  ,fEND"  will  most  likely  be 


added  to  the  syntax  later. 
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<set  switch  statement>  ::=<switch>  :=  [<switch>  |  <*N>  |  [MAX   MIN] 

(LIST  <switch>  SEPARATOR  , ) ] 
<step>  ::=  <procedure  call>  |  <procedure  body>  |  <file  identifier>  | 

(<parallel  statement>)  |  Conditional  logic  statement>  |  STOP 
<procedure  call>  ::=  <*I>  <calling  parameter  list>? 

<calling  parameter  list>  ::=  (LIST  [<*I>  =  <file  identifier^  SEPARATOR  ,) 
Conditional  logic  statement>  ::=  IF  <boolean>  THEN  (<parallel  statement>) 

ELSE  (<parallel  statement>) 
<boolean>  ::=  <switch>  [<  |  >  |  =  |  NEQ  |  LEQ,  |  GEQ]  [<*N>  |  <switch>] 

The  logic  card  allows  the  user  to  specify  the  logical  sequence  in 
which  his  tasks  are  to  be  processed.   Tasks  separated  by  "ALSO"  or  "&"  will  be 


"ivrn-u-m"        M   " 


processed  in  parallel.   The  appearance  of  NEXT  or  ;   implies  that  all  pre- 
vious tasks  must  be  completed  before  the  next  task  is  initiated.   "ALSO"  or 
"&"  takes  precedence  over  "NEXT"  or  "j "  but  parentheses  allow  the  user  to 
specify  any  ordering  since  the  expression  within  the  parentheses  is  evaluated 
first.   The  conditional  logic  statement  provides  further  control  by  allowing 
conditional  execution  of  tasks. 


2.2.2  Conditional  Logic  Statement 

In  the  conditional  logic  statement  the  value  of  a  switch  is  compared 

2k 
to  another  switch  or  to  an  integer  between  1  and  2-1.   If  the  result  of  the 

comparison  is  true  the  parallel  statement  following  the  "THEN"  will  be  executed; 

if  the  result  is  false  the  parallel  statement  following  the  "ELSE"  will  be 


not  implemented  in  first  edition. 
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executed.   The  parallel  statements  following  the  "THEN"  and  "ELSE"  must  be 

enclosed  in  parentheses. 

EXAMPLES: 

IF  SW10  >  5   THEN   (STOP)   ELSE    (A  &  B) 

IF  SW20  NEQ  SW17   THEN   (A)   ELSE    (IF  SW6  LEQ  200  THEN   (A)  ELSE 
(C  NEXT  D)   ALSO  R) 

2.2.3     STOP 

The  special  reserved  word  "STOP"  when  executed  stops  all  further  pro- 
cessing and  indicates  that  the  user's  job  is  to  be  terminated. 

2.2.  k     STEP 

A  step  then  can  be  a  conditional  logic  statement,  a  "STOP",  a  proce- 
dure call,  or  a  procedure,  or  it  can  be  a  file  identifier.   The  file  referred 
to  by  the  file  identifier  must  contain  more  ICL  which  is  inserted  at  this  point. 
When  the  ICL  on  this  file  is  exhausted  control  will  be  returned  to  the  original 
file. 

2.2.5  Switch  Set  Statement 

To  avoid  race  conditions  set  switch  statements  can  occur  only  after 

a  "}"   or  "NEXT".   Switches  can  be  set  from  other  switches,  to  any  integer  be- 

2k  , 

tween  0  and  2  -  1  or  the  maximum  or  minimum  of  a  list  of  switches  (where  the 


list  has  maximum  length  of  six  switches) 


Note:  Go  tos  are  not  allowed  since  before  any  task  can  be  sent  off 
to  be  processed  all  tasks  that  precede  it  must  be  completed.   Keeping  track  of 
all  possible  paths  and  the  corresponding  number  of  preceding  tasks  per  path 
that  must  be  completed  would  increase  the  complexity  of  the  job  parser  by  an 
estimated  factor  of  2. 
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EXAMPLES: 

SW1  :-  SW5 
SW1  :=  257 
SW17  :=  MAX  (SW2,  SW3,  SWk,    SW6) 

2.2.6  Example  of  Logic  Card 

The  job  parser  interprets  the  user's  ICL  creating  a  tree  which  repre- 
sents the  logical  structure  of  the  user's  job.   Each  node  of  the  tree  is  an  en- 
coding of  a  conditional  logic  statement  including  a  true  and  a  false  pointer 
corresponding  to  the  THEN  and  ELSE  branches,  or  a  switch  setting  statement 
which  has  only  a  sequential  pointer,  or  a  task  to  be  executed  which  has  a  se- 
quential and  a  parallel  pointer,  or  a  join  which  brings  together  the  THEN  and 
ELSE  branches  and  which  has  a  parallel  and  a  sequential  pointer,  or  a  STOP 
which  has  no  pointers. 

A  &  IF  SW2  >  10  THEN  (C  &  (D  NEXT  F))  ELSE  (G  &  H  NEXT  R)  &  Z  NEXT  SW5:=  200 
NEXT  Q; 

The  above  ICL  generates  the  symbolic  tree  of  Figure  1  where  S  = 
sequential,  P  =  parallel,  T  =  true,  F  =  false  and  an  "X"  in  the  pointer  indi- 
cates that  the  pointer  is  null.   Single  letter  identifiers  are  procedure  calls. 

2.3  An  ICL  Program 

2.3.1  Control  Program 

<control  program>  : :=  <accounting  card>;  [<library  card>;]  * 

<procedure  declaration>  *  <logic  card> 
<accounting  card>  ::=  <  to  be  specified  > 


Ik 


IF 


»     S 


H 


+  S 


]SJ 


R 


*  S 


1SJ 


■  ^C 


F 


^ 


ft? 


JOIN 


^ 


UI 


Set   switch 


^ 


Q, 


1X1X1 


Figiire  1.      Logic   Tree. 
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2.3-2  Library 

<library  card>  : :  =  LIBRARY  =  LIST  <B6500  disk  file  name>  SEPARATOR  , 

A  library  card  gives  a  list  of  disk  files  or  libraries  which  contain 
procedures.   Any  procedure  called  in  logic  card  must  be  declared  or  be  found  in 
a  declared  library. 
EXAMPLE: 

LIBRARY  =  LIB1/NAME/PR0CS,  LIB2/PR0CS 
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3.   IMPLEMENTATION:   THE  JOB  PARSER 

3-1  Introduction 

There  is  a  job  parser  attached  to  each  user.   The  job  parser  inter- 
prets the  user's  ICL,  builds  a  tree  which  describes  the  logical  structure  of 
the  user's  tasks  and  dossiers  or  tables  which  describe  the  tasks,  initiates 
tasks,  and  cleans  up  after  the  completion  of  a  task.   The  job  parser  is  really 
two  modules;  the  first,  the  builder,  builds  the  tree  and  the  dossiers.   The 
second,  the  doer,  runs  down  the  tree  sending  off  ILLIAC  tasks  to  the  disk  file 
allocator  and  B6500  tasks  to  the  B65OO  scheduler.   The  builder  will  be  discus- 
sed first. 

3.2  The  Tree  Builder 

As  mentioned  in  the  syntax  description  section,  each  type  of  step  in 
the  logic  card  generates  a  different  type  of  node  in  the  tree.   A  set  switch 
step  generates  this  node: 


sequential  pointer 


last  3  switch  indices  in  max. -min. 
list  or  unused 


index  of 
switch  tc 
be  set 


no.  of 

nodes 

that 

join 

here 


no.  of 
nodes 
that  join 
here  that 
are  done 


first  3  switch  indices  from  max. -min. 
list  or  switch  index  or  integer  from 
which  first  switch  is  to  be  set. 


1+7  k6  k\ 


k^k3ik2  kl  33  28  23 
1  if  set  from  max  or  min 


1  if  max,   0  if  min 


1  if  set  from  another  switch 


EXAMPLE:   SW10:=  MAX  (SW2,  SW3,  SW*+,  SW5) 


not  filled  in  yet 


n 


0 


0 


10 


not 
in  yet 


filled  fil 


.led 
oy  doei 


1+7  1+6  1+5  kk  ^3  k2  kl 


33 


28 


23 
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A  conditional  logic  statement  generates  this  block: 


true  pointer 


false  pointer 


switch 
index 


kj  k6  k5 


compar- 
ison 
code 


3% 


no. 

join 
here 


no.  nodes 
joining 
done 


switch  index  or  integer  to  be  com- 
pared to 


33 2$ 


37 


23 


1  if  compare  to  switch 
0  if  compare  to  integer 


,EQL  0 
NEQ  1 


LSS  2 
LEQ  k 


GTR  3 

GEQ  5 


EXAMPLE : 


IF  SW10  >  200  THEN  (A  &  B)  ELSE  (C)  generates: 


pointer  to  A 

pointer  to  C 

0 

0 

10 

3 

0 

not  filled 
in  yet 

not  filled 
in  yet 

200 

1+7  k6   h5       37  3^  33 


28 


23 


The  join  node  that  corresponds  to  each  if  has  the  following  format 


sequential  pointer 


parallel  pointer 


no .  node  s 
joining 
here  from 
false 
branch 


no.  nodes 
joining 
here  from 
true 
branch 


no.  of 

nodes 

that 

are 

done 


pointer  to  if  that  gener- 
ated the  join 


47  1+6 


Uc 


39  38  37 


3^  33 


28 


23 


0  if  corresponding  if  is  false,  1  if  true 
(filled  in  by  doer) 


EXAMPLE: 


not  filled  in  yet 


not  filled  in  yet 


WT6k5 


filled 
by  doer 


filled 
by  doer 


pointer  to  if 


w 


39  38  37  33  28 


23 
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A  procedure  call  or  a  procedure  body  generates  an  execution  node  with  the 
following  format : 


sequential  pointer 


switch  to   \  / 
be  set  from  v 
condition 
code 


parallel  pointer 


^ 


no.  nodes 
that  join 
here 


no.  nodes 

joining 
here  that 
are  done 


pointer  to  dossier 
or  zip  file 


h3 


35  3^ 


33       28       23 

1  if  restart  after  halt  load 

1  if  done 

1  if  initialized 

1  if  zip  file  pointer  (B6500  task) 


filled  by  doer 


Procedure  logic  determines  what  type  of  step  the  ICL  specifies.   If 
it  is  a  procedure  call  or  procedure  body,  procedure  EXECUTECARD  is  called  to 
determine  whether  the  task  is  an  ILLIAC  or  B6500  task.   If  it  is  a  B65OO,  a 
zip  file  is  created  and  a  pointer  to  the  zip  file  is  inserted  in  the  corres- 
ponding node.   If  it  is  an  ILLIAC  task,  dossiers  describing  the  task  are  gener- 
ated.  The  ILLIAC  dossier  has  the  format  specified  in  Table  1. 

The  ILLIAC  dossier  points  to  the  disk  file  requests.   Each  ILLIAC 
task  generates  at  least  one  file  request—that  of  the  program  file.   Each  addi- 
tional ILLIAC  TV  file  generates  a  new  dossier,  and  all  file  dossiers  are  linked 
together.   The  format  of  the  file  dossiers  is  given  in  Table  2.   They  are  gener- 
ated by  procedure  I^FILE  CARD  which  parses  the  Initialization  part  and  which 
calls  PREFIX  and  MAPLIST  to  parse  the  disk  map  part. 

B6500  file  cards  referring  to  job  partner  data  files  are  handled  by 
storing  the  card  image  in  a  disk  block  and  pointing  to  it  from  the  ILLIAC 
dossier. 

Since  the  external  B65OO  disk  file  name  may  be  arbitrarily  long, 
special  blocks  are  designed  to  contain  these  names.   The  pointer  to  the  job 


TABLE  1 

THE  ILLIAC  DOSSIER 
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WORD 

FIELD 

L 

0:1 

[47:2U] 
[23:24] 

L 

1:1 

LS 

2:1 

L 

3:3 

L 

6:3 

L 

9  =  3 

FS 

12:1 

[1+7:24] 
[23:24] 

S 

13:1 

FS 

14:1 

[47:24] 
[23:24] 

L 

15:1 

[1+7:21+] 
[23:24] 

16:1 

[47:24]FS 
[23:24]S 

S 

L 

17:1 
18:1 

19:1 

[47:8]L 

[39:8]L 

[31:8]FS 

[23:8]FS 

[15:2]S 

[13:1]L 

[12:1]L 

[11:1]L 

[10:1]L 

[  9:1]L 

[  8:1]L 

[  7:1]L 

L 

20:1 

[33:8] 
[25:4] 
[21:5] 
[16:17] 

L 

21:1 

S 

22:1 

[23:24]S 

23:7 

FIELD  CONTENTS 

link  to  the  next  older  lead  dossier  (DISK  ALLOC] 

link  to  the  next  younger  lead  dossier  (DISK  ALLOC] 

job  ID  number  (JOB  PARSER] 

job  step  number  (JOB  PARSER] 

project  ID  (JOB  PARSER] 

user  ID  (JOB  PARSER] 

access  code  (JOB  PARSER] 

pointer  to  the  next  sequential  step  (JOB  PARSER] 

pointer  to  the  next  parallel  step  (JOB  PARSER] 

step  condition  code  (EXEC  MONIT) 

pointer  to  the  file  map  table  (DISK  ALLOC] 

pointer  to  the  file  name  table  (DISK  ALLOC] 

pointer  to  the  preprocess  requests  (DISK  ALLOC] 

pointer  to  the  postprocess  requests  (DISK  ALLOC] 

pointer  to  the  disk  file  requests  (JOB  PARSER] 

pointer  to  the  job  partner  name  (JOB  PARSER] 

maximum  time  for  this  step  element  (NS)  (JOB  PARSER] 

maximum  time  for  the  whole  job  (MS)  (JOB  PARSER] 

category  requested  (JOB  PARSER] 

category  received  (DISK  ALLOC] 

step  level  (JOB  PARSER] 

number  of  steps  that  join  here  (JOB  PARSER] 

number  of  quadrants  required  (JOB  PARSER] 

dossier  built  (JOB  PARSER] 

request  queued  (DISK  ALLOC] 

file  space  allocated  (DISK  ALLOC] 

data  preprocessed  (D  PROCESSR] 

execution  completed  (EXEC  MONIT) 

data  postprocessed  (D  PROCESSR] 

file  space  freed  (DISK  ALLOC] 

year  (69,  70,  etc.) :"\  time  of  (JOB  PARSER] 

month:  /entry  (JOB  PARSER] 

day:  '     I  into  (JOB  PARSER) 

time  (seconds):     J  system  (JOB  PARSER) 

time  of  entry  into  disk  file  allocator  (DISK  ALLOC] 

pointer  to  job  partner  data  files  (JOB  PARSER, 
reserved  for  future  expansion 


TABLE  2 
THE  ILLIAC  FILE  DOSSIER 
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WORD 


FIELD 


0:1 

07:24] 

[23:24] 

1:3 

4:3 

7:1 

[47:24] 

[23:24] 

8:1 

[47:24] 

[23:24] 

FIELD   CONTENTS 

number  of  words  used  in  this  "block 

pointer  to  next  block 

file  name 

unused 

number  of  segments/record 

total  number  of  segments  in  the   file 

pointer  to  preprocess  requests 

pointer  to  postprocess  requests 

Starting  at  word  8  and  continuing  until  the   file   is  exhausted  are  two- 
word  blocks   specifying  the   segment  relations.      The  file   specification 
is  terminated  by  a  two -word  block  containing  zeros. 

9:1  [47:24]  segment  number  to   start  at 

[22:24]  number  of  segments,    including  above,    involved  in 
this   specification 

10:1  [43:1]    =1  if  specific   segment  is  required 

[42:1]   =1  if  the   space  is   contiguous 

[4l:l]    =1  if  the   space   is  phased 

[40:1]   =1  if  a  virtual  EU  is  required 

[39:1]   =1  if  a  virtual  SU  is  required 

[38:1]   =1  if  a  virtual  TRK  is  required 

[37:1]    -  1  if  a  specific  EU  is  required 

[36:1]    =1  if  a  specific  SU  is  required 

[35:1]   =1  if  a  specific   TRK  is  required 

[34:4]  EU  number 

[30:8]  SU  number 

[22:10]  TRK  number 

[12:13]  phase    (in  terms  of  segments) 
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partner,  pointer  to  preprocess  and  pointer  to  postprocess  requests  point  to 
these  kinds  of  blocks.   The  format  is  given  in  Table  3  and  an  example  in 
Figure  2. 

TABLE  3 
B6500  DISK  FILE  NAME  BLOCK 


0:1    [1+7:2^] 
[23:24] 


number  of  words  used  in  this  block 
pointer  to  next  block 


Starting  at  word  1  and  continuing  until  the  name  is  exhausted  are  three- 
word  blocks.   The  n-th  block  contains  the  number  of  characters  and  the 
n-th  identifier  or  the  name. 


1:1    [1*7:6] 

[41:1+2] 
2:2 


number  of  characters  of  identifier  (for  BCL  input) 
first  7  characters  of  identifier 
remainder  of  identifier 


0 

9 

1 

2 

'  m      y 

2 

3 

4 

5 

F 

I 

R 

s 

T 

5 

6 

7 

10 

p 

R 

0 

G 

R 

A 

M 

8 

L 

1 

B 

9 

10 

29 

Figure  2.   B6500  DISK  FILE  NAME  BLOCK  FOR  MY/FIRST/PROGRAMLIB. 
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The  tree  builder  might  be  best  understood  by  considering  an  example 
of  a  task  and  constructing  the  appropriate  disk  blocks. 

EXECUTE  SW10  :=  SYS/PARSER  ON  ILLIAC  IV  (l)  WITH  PARSER/'PARD  FOR  5; 
FILE  B  =  (8  MOVE  ON  A/B  MOVE  OFF  C/D)((@EU1,  @SUO,  @TRKO) 
(0:   600  SEGMENTS),  SU1  (•+(():   10,  10MS:   20)), 
100C,  500,  200C) 
generates  the  disk  blocks  of  Figure  3* 

3.3  The  Doer 

The  doer  runs  in  parallel  with  the  builder.   It  begins  at  node  0  of 
the  tree  and  runs  down  the  tree  sending  ILLIAC  IV  tasks  to  the  disk  file  alloca- 
tor and  B6500  tasks  to  the  B65OO  scheduler.   It  also  checks  for  tasks  that  have 
been  completed,  freeing  the  disk  blocks  belonging  to  that  task. 

A  task  is  sent  off  provided  that  all  tasks  which  logically  precede  it 
have  been  completed.   The  doer  works  by  chasing  down  the  parallel  pointers, 
sending  off  tasks,  until  a  null  or  empty  parallel  pointer  is  reached.   It  will 
then  back  up  and  chase  down  sequential  pointers.   When  it  can  send  off  no  more 
tasks,  it  will  check  for  completions  and  begin  again. 

The  doer  proceeds  according  to  the  following  algorithm: 
1.   Number  of  nodes  that  join  here  is  not  equal  to  number  of  nodes  that  join  here 
that  are  done—put  node  in  WAITS  stack  and  go  to  2,  else  continue. 

1.1  Stop  node — quit. 

1.2  If  node — evaluate  if,  go  to  true  or  false  node. 

1.3  Set  switch  node — set  the  switch,  go  to  next  sequential  node. 
1.1+  Join  node — go  to  1.5*2. 


Assuming  two  processors  on  the  B6500,  it  is  started  after  the  builder 
so  that  it  will  have  some  data  to  work  with. 
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JOB  PARTNER  NAME  f 

0 

7 

0 

1 

2 

4 

p 

A 

R 

r. 

a 

^^^^^==~~~ 

as 

2fi 

™r==»-<r" 

POSTPROCE3S 

\ ' 

0 

7 

1 

1 

C 

2 

S 

4 

1 

D 

8 

a 

7 
9 

—v~— 

t» 

— r , 

KEY>     i/     FILLED  IV  PROSRAM  OTHER  THAN  JOB  PARSER 

M       NOT  USED  IN  FIRST  EDITION  OF  THE 

OPERATING   tlTHCM 
?       FILLED  IN  LATER  OR  NOT  KNOWN  FROM 

INFORMATION  OIVEN 


NOTE-  KL  INPUT  ASSUMED 


Figure  3«      Disk  Blocks. 
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1.5  Execution  node 

1.5.1  Send  off  task  to  disk  file  allocator  or  B6500  scheduler. 

1.5.2  Both  parallel  and  sequential  pointers  empty,  put  node  in  PAREMPTY  and 
SEQEMPTY"  stacks,  go  to  2. 

1.5. 3  Sequential  pointer  empty,  put  node  in  SEQEMPTY  stack;  parallel  pointer 
null,  go  to  2,  else  get  node  pointed  to  by  parallel  pointer  and  go  to  1. 

1.5.4  Parallel  pointer  empty, put  node  in  PAREMPTY  stack;  sequential  pointer 
null,  go  to  2,  else  get  node  pointed  to  by  sequential  pointer  and  go  to  1. 
1.5-5  Sequential  pointer  not  null,  parallel  not  null, put  node  in  SEQSKIP  stack 
if  not  there  already,  get  node  pointed  to  by  parallel  pointer  and  go  to  1; 
parallel  pointer  null, get  node  pointed  to  by  sequential  pointer  and  go  to  1. 
1.5-6  Sequential  pointer  null,  parallel  pointer  OK,  get  node  pointed  to  by 
parallel  pointer  and  go  to  1. 

1.5-7  Both  null,  quit. 

2.   Get  here  if  nothing  else  can  be  sent  off. 

2.1  Something  has  been  completed,  set  done  bit,  repeat. 

2.2  No  more  completions. 

2.2.1  Check  WAITS  if  anything  can  be  done,  now  get  node  number  and  go  to  1. 

2.2.2  Go  through  the  SEQEMPTY  stack  to  see  if  any  sequential  pointers  have 
been  filled  in — if  so,  transfer  node  to  SEQSKIP  stack  if  not  there  already. 

2.2.3  Go  through  PAREMPTY  stack  if  any  of  the  parallel  pointers  have  been 
filled  in — get  node  and  go  to  1. 

2.2.4  Go  through  SEQSKIP  stack— get  first  node  and  go  to  1. 

2.2.5  Go  to  2. 
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APPENDIX 
ICL   SYNTAX 


<CUNTROL  9^D6KAM>: t«<ACCOUNTING  CARD>  <LI13RARY  CARD>* 
cPRpfFbUPfc  DECLARATION  CARD>*<LnGIC  CAPD> 

<L1BPARY  :aR0>II«L IPKARY»<FILF  NAME  LIST>i 

<F  ILF  NA"r  LISt>««*i IST<R6500  DISK  FILE  NAMf>  SEPARATOR  > 

<PROCEDURi  DECifRATIbN  C ARD>ll «PROCEDURE<* I>  <PARAMETER  LIST>? 
<TN«rRT>?;<PHOCFDI)RF  BODY>j 

<PARAMETT,  LIST>» »afLrsTf<*I><OEFAULT>?]SEPARATOP  »> 

<ULFAULT>II«    3<H[t    l9FMIFIEf<> 

<INSFRl>t|«  IN  <P».50H  DISK  FILF  NAMF> 

<PR0CEDli«»r  ppDv>:  «e<EXFCUTE  CARD>/REGlN  <STFP  Rl  rC*>  END 

<LxECUTE  :ARD>:  t*LXECljTE  <SwTTCHSET>?  <PROC.RAM  NAMF>  ON 
<HAr"lKE  KAML>  <TIMF  LIMIT>?; 

<SNITCHSPT>I |s<SWJTrh>|« 

<SWlTCH>i tBSW<*K> 

<PROGKAM  vAMF>t  l»<FRE  1PENT1FIER> 

<MACHINE  \AHE>I »  =  l  I  «/ I LL I  AC  I V/ ILL  I  AC  I  V  J t ( t /2/3/4  )  1?/b65C0 

<TIMF  Ll'MT>.  »«FP|.  <*N> 

<STEP  BL0CK>I  :«r<F XECUTE  CARD>fIA  FILE  CARD>*/ 

<Po500  FILE  CARD>*]*]*/ 

«ANv  LL6AL  R6500  CONTROL  CARD  SEQUENCE  WITH  ? 

REPi  KED  bY  t*i 
<L0GIC  CA^D>t  JeHF(,U'  <LOGlC  HODY>  END/<pROCEDllRF  fALL> 
<LOGIC  PHDYlt*  tTs»  <PARALLEL  STATEMENT>  SEPARATOR 1 1 /NEXT  ] 
<PARALLF|.  STATF^FnI>»  » =  L I ST<STFP>SEPAKATORt 8/ALSO 1/ 

<SET  SWITCH  STPT> 
<SET  SHIT:"  SI  Ml > I  ir<SWlTCH>|«t<SWlTCH>/<*I>/ 

[MAy/MjN](LTsT<SWlTCH>SEPARATC)R#  )I 
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<STEP>I l*«PROCrni»ht  CALt>/<PROCEDURE  BOOY>/ 

<ft|  t  jOfNTIF IFR>/(<PARALUL  STATFMFNT>>/ 

<CJNnTlIONAL  LOGIC  *TATEMENT> 
<PROCEDURr  CAL|>U«<*I>  <CALLING  PARAMFTFR  LlST>? 
<CALLlNG  'ArAmftFh  i  J  ST>  1 1  «(L  I  ST  t  <♦  I  >»<F  Il_F  IDENTIFIER>  3 

SEPARATOR  >) 
<CONniTin\(AL  LPGH  fTATEMFNT>«  t«!f  <BUOLFAN>  THFN 

(<PAPALLFL  STATEMENT>)  ELSt ( <PARALLEL  $TATtMENT>) 
<BOPUAK>i j=<b^lTth>r</>/«/NE«/LFO/GEo]t<*N>/<SW!TCH>J 
<I*  FILF  CARD>I  t«F  HE  <*I>«r<INlTlALl7ATlON  PART> 

(<DI«K    MAP    PAR1>)J]/    IMMED1ATF    <pATA>    f*    ENDDATA 

<D1SK    MA"    PaRT>»  *«<F  REF!*>C<MAP    EIFMEnT    l.lST>)/ 

<"Ap    F[EPtNT    LIST>/    SIZE    UF    <B6500    DISK    FILE    NAME> 

<PREFlX>t:=<*N>/f*  3?<LntATION>/<LOCATION    LTST> 
<LOCA7IPM>t  t«E|i*Fl.NP>/SH<SUNf)>/TRK<TRhNO>/SFG<PHASE> 
<PHASE>t t*<AMY     IwiLGtR    UFTWFFfc    o    ANp    11992 
<L0CATIPN    LlST>»lsUlST    <!-OCATIpN>    SEFARATpR    O 
<EUNP>»  ».3D/1 

<SU^P>«  »«3/l/*/3/<4^/iS/7/P/9/lO/ll 
<TRKN0>»  l«ANY    IKUGFH    RETKEEN    0    AkP    «7> 
<MAP    ELEMENT    L!ST>iibLIST    <MAP    ELEMENT>    SEPARATPR    # 
<MAP    LLF*Oi>  t  |«<*N><«UALIFIFR>K*N><S17F    QUALIFIFR>/ 
<*N><5IZF    OUALIFIF R>-<*N><SIZF    OljALlFIFR>    / 

<*N><P|.AL  lFIFR>KRf  PETITIVE    F|   \>/ 
<*N>C<biZF    0UALIFIER>/ 

<*N><T(,U»L>/ 

<PRFPTX>(<MAP  Fl.FMENT  IIST>) 
<TQUAL>i  t»lR/S/HsA*Y  ALPHAMERIC  SEOUINCFJ/O 
<SI7F  QUA.lFIEpH  i*rR/SJ*AMY  ALPHAMERIC  SE0UAmCE*/<> 
<QUAl  IFIf  9>  «  »«rPA/R/$]£AfcY  ALPHAMERIC  SFQUENCE>/<> 
<REPF7ITTvF  FLT>»  »  *(  <  *N>P<*N><QijALlF  IE  R>  K*N>  > 
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<IN!TULT*MTO|w    PARTt J=(<SEGMENTS    PER    RECURD>? 

<MOt  PS  FART>)/<> 
<SEGMJNtS  PfR  RECURP>:  »=<*N> 
<MOT!ON  PART>l|«^OVF  ON(<SOuRCE>) 

MOVf  PFFcr<P6*00  DISK  FILE  NAME>/*<M>  1  > 
<SOURCE>» !»LISTf<B6500  DISK  FILE  NAME>/#<M>J  SEPARATOR  ft 
<B6500  FTlF  CArD>:  IbF  TLF.  <*I>*<FUE  IDENT1FIER> 
<B6b00  DT$K  FI,t  nMK>ii«i  IsT<*I>  SEPARATOR/ 
<UMT  FIL£>Ms<Tn  BF  SPFCJFIFD> 
<FlLF  IUFsil  If1ER>I  l«<M<S5nn  DISK  FILE  NAmE><OPT  IPKS> 

/<IMMFC1ATF  FILF>/<UNIT  FILE>/*<*I> 
<OPTTONS>  t  1  «<Tp  PF.  SFFCIFIED> 

<IHMfDIAT[;  F  I  LP>  t  1 »F I LF<*I >*T MM^D! ATE  SDATA*  *#  F^HDATA 
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